Clean up hardware abstractions#20
Open
ReeceStevens wants to merge 8 commits into
Open
Conversation
`System.h` contained way too many disparate parts. Separated hardware abstractions from each other to make the libraries easier to read and understand. Some more work still is to be done on UART libraries and separating out a console from a UART interface. In addition to this, future commits will work on cleaning up the abstractions for the display hardware and, eventually, the display software abstractions as well. The focus of these commits is to reduce the number of monolithic classes and decrease average function size.
The logging macro borrows heavily from the design @Jacobingalls created for logging during OS development. It provides four levels of logging as well as colored console output. The logging macro resolves to an empty line when the program is being compiled in production mode and a log statement when compiled in development mode. The Makefile was updated to reflect this change: `make prod` --> Compile in production mode `make dev` --> Compile in development mode By default, the Makefile will compile in development mode. Finally, the USART module was broken apart from the Console module and expanded to cover all possible USART channels and pin combinations.
Logger depends on the SWI interface to use `printf`, not USART. As such, no USART setup is required to start logging. Also updated the logging file to a more appropriate name.
Goal is to separate the monolith `ECG_Readout`, `NIBP_Readout`, and
`PulseOx` classes into their constituent components:
1. Hardware-level drivers
Interface: Read and write data, issue device commands
2. Samplers
Interface: `get_buffer_data` safely copies the sample buffer into a
vector for further processing.
3. Processor thread
Performs useful calculations on the buffer data. Is "threaded" by
the use of timer interrupts with controlled priority levels.
4. Display Sandbox
Takes the buffer data in a SignalTrace (if applicable) and the
outputs of the processor thread to display on the GUI.
This commit begins with the SpO2 class since it has unique properties
(in particular, there are actually two values being sampled per
interrupt and thus two samplers must be made).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Things got a bit too sloppy during the rush to complete the prototype in time for Nepal, so we're going to go back over and clean up these abstractions to achieve the following objectives:
configure_GPIO()should do all the work necessary to configure a GPIO, even if it's a special case like an alternate function)